Skip to main content

Message Store

The message store defines a flexible infrastructure for storing and reading messages within Orchestra. Within Orchestra, messages are the main carrier of every information that is processed within the system. Since different interface scenarios have different requirements like performance or message size, the message store has to be flexible enough in order to cope with this different requirements. Messages are divided into two groups:

  • Structured messages: Structured messages are defined as hierarchical data structures that are presented as XML documents to the user. Note, this is only the view messages are presented to the user. Internally, messages can be stored in different ways. The serialization format depends on the requirements of a interface scenario. Therefore a hybrid message serialization is available. This format is flexible enough to support the different requirements.

  • Binary message: Every data like pictures, PDF, ... where the content is not relevant for the processing can be defined as binary messages. Binary message present thier content as binary streams. A hierarchical, structured access is not possible.

Structured Volatile Messages​

  • high performance
  • messages are stored in memory
  • No overhead due to repeated message parsing
  • No message state is stored in the database

Structured Persistent Messages​

  • messages are stored as plain xml stream in the internal Orchestra database
  • robust against errors and system restarts
  • Reduced performance due to overhead for persisting and re-parsing of messages

Structured Mass Data Messages​

  • Messages are stored in a special binary format to the database
  • A hierarchical messages is divided into pages of 4 megabyte size.
  • When ever a message is accessed only a small number of pages is loaded into memory
  • The message structure is completely presented as hierarchical data to the user

Whenever messages or message lists are stored persistently, orchestra needs to ensure that all messages that are referenced by e.g. processes and workitmes are kept as long as the owning objects exist.

Currently the following locking modes are supported:

  • DISABLED - The locking of messages is switched of completely. Each message or message list receives a default lease time upon creation. The lease time has to high enough so that all messages are processed before the are deleted

  • QUEUE - Only messages contained in queues are locked by use of reference counting. As long as the reference counter is not null, the messages will be kept in the message store. Whenever a message is used by a process, the lease time is increased by the maximal life time of finished processes.

  • DEFAULT - The default locking approach where all messages are locked. In this situation locks are stored in two database tables. This mode was used by older orchestra implementations. It needs a lot of resources and has a poor performance.

  • OPTIMIZED - This mode uses reference counting whenever a message is referenced by a queue or a process instance. This mechanism is the recommended approach for newer orchestra instances

Whenever a default lease time has to be used, the new parameter "messagestore.message.leastime" has to be used. It defines the default lease time of messages or message objects. When the leastime is not configured properly, as default one day is used.